In a typical signal distribution system providing Internet protocol television (IPTV) over digital subscriber line (DSL) or fiber, a subscriber or user is provided with an interface device, such as a set-top box (STB) or receiver, for communicating with network equipment, which may comprise, for example, a DSL access multiplexer (DSLAM). The interface device is configured to receive and process for presentation on a television or the like, a content stream corresponding to a channel selected by the user.
In order to receive a given selected channel in an IPTV system, the subscriber interface device will typically join a multicast stream corresponding to the selected channel. This is problematic in that there can be a substantial delay, on the order of several seconds, between user entry of a channel change command and receipt of decodable multicast data for the new channel. Because decoding the video stream is typically a recursive process, i.e., decoding a frame relies on previously decoded frames, decoding must start at an “entry point,” where no prior frames are needed. Therefore, once an STB joins the multicast of a new channel, it has to wait for the next entry point in the stream in order to begin decoding. The interval between such entry points, however, may be hundreds of milliseconds or even seconds. This is the major cause of delay in channel change. During this channel change delay period, the screen of the presentation device is usually blank or frozen, which can be particularly annoying to the viewer when channel surfing.
One approach used in IPTV to address the problem of channel change delay has been to deploy fast channel change (FCC) servers in the distribution system. An FCC server caches the last few seconds of the content stream for each channel. In response to a subscriber's entry of a channel change command, the subscriber's STB sends an FCC request to the FCC server. The FCC server sends in unicast to the STB a short stream of video from the new channel for immediate playback, starting at some entry point in the past (behind the current multicast packet). The FCC server sends the data to the STB at a data rate faster than the channel's data rate, in which case, after a few seconds, it “catches up” with the multicast stream for that channel. The STB begins playing the new channel shortly after it receives the first unicast packet; hence the channel change appears to be fast. Once the FCC server “catches up” with the multicast, it signals the STB to join the multicast stream for the new channel. The STB joins the multicast and continues to play from the multicast stream. A description of an exemplary implementation of this conventional approach can be found in U.S. Patent Application Publication No. 2005/0081244, entitled “Fast Channel Change.”
Generally, the subscriber's loop (between the STB and DSLAM) is of limited bandwidth. If the FCC server were to send the FCC unicast to the STB at the channel's data rate in parallel to the multicast, packet loss might occur. To prevent such an occurrence, shortly after signaling to the STB to join the multicast, the server drops the unicast rate to a fraction of the channel data rate. Therefore, during the time from receiving the “join multicast” signal until beginning to receive the multicast input, the STB receives data at a rate significantly lower than the rate at which it consumes data, with the balance obtained from a buffer which had been accumulated before, when the server unicast rate was higher than the channel data rate. In order to prevent the buffer in the STB from running out before decoding of the multicast stream begins, the server has to select the starting point at a sufficiently long delay.
A significant drawback of the conventional FCC approach, however, is that the amount of data per FCC transaction is very sensitive to the variability of the multicast join time, that is, the time from sending a join request until receiving the first multicast packet. This interval can be modeled as a random variable with a long-tailed distribution that can vary from a few milliseconds to several hundreds of milliseconds. As such, provisioning a conventional FCC system for all cases of multicast join time results in a major increase in FCC transaction duration, which for most cases is not needed, and makes it harder to scale-up the FCC system to handle greater numbers of FCC transactions.
Another approach to the channel change delay problem relies on a high bandwidth link to the subscriber. Generally, using more bandwidth alleviates the problem, but due to limitations in the distribution system, additional bandwidth may not be available or cost-effective.
Thus, there is an unsolved need to adequately reduce the duration and amount of data sent of the unicast streams sent by a FCC server when subscribers change channels for video distributed in an IP network environment.